This disclosure relates to profiling transactions on an integrated circuit chip.
In the past, an embedded system which had multiple core devices (processors, memories etc.) would have been incorporated onto a Printed Circuit Board (PCB) and connected on the PCB via buses. Traffic in the embedded system was conveyed over these buses. This arrangement was convenient for debugging the core devices, because debugging tools such as oscilloscopes and logic analyzers could be attached to the PCB's buses allowing direct access to the core devices.
Market demand for smaller products coupled with advances in semiconductor technology has led to the development of System-on-Chip (SoC) devices. In a SoC, the multiple core devices of an embedded system are integrated onto a single chip. In a SoC, the traffic in the embedded system is conveyed over internal buses, thus connection of debugging tools directly to the system bus is no longer possible. The resulting reduced access coupled with an increasing quantity of data being transported around the chip (due to developments of SoC technology leading to integration of multiple processing cores and higher internal clocking frequencies), has reduced the ability of external debugging tools to find and solve bugs within the system in the timescales demanded by the industry.
Thus, the development of SoC devices required associated development in debugging technology, which lead to the integration of some debug functionality onto the SoC. It is now customary for on-chip debugging circuitry to monitor transactions on the internal buses of the SoC under the control of an off-chip debugger.
As well as detecting bugs, debug functionality may additionally be utilised to profile memory usage on the SoC. Specifically, it can monitor activity of the code being implemented. The data collected is sent to the off-chip debugger, where that data is analysed. As a result of this analysis, the debugger may reconfigure the on-chip memory functionality so as to optimise memory usage on-chip. Profiling can be done by instrumenting the code. This method is precise but intrusive and may change the timing of the program being profiled. Alternatively, profiling can be done by periodic sampling. This is less intrusive but less precise because the inter-sample behaviour is not captured.